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I. REAL PARTY IN INTEREST 

The real party in interest for this appeal is: 

Bentley Systems, Inc. 
685 Stockton Drive 
Exton,PA 19341-0678 



II. RELATED APPEALS, INTERFERENCES, AND JUDICIAL PROCEEDINGS 

There are no other appeals, interferences, or judicial proceedings which will directly 
affect or be directly affected by or have a bearing on the Board's decision in this appeal. 



III. STATUS OF CLAIMS 

A. Total Number of Claims in Application 
There are 34 claims pending in application. 

Claims 83-1 16 have been finally rejected in the Office Action of February 8, 2007. 
Claims 83-1 16 are being appealed. Claims 1-82 have been withdrawn. 
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IV. STATUS OF AMENDMENTS 

No claim amendments were made after final rejection. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

As recited in claim 83, a file format 200 uses variable-sized data records, or elements, stored 
in element chunks 320, to store data in a file on a computer readable medium (specification page 6, 
lines 29-31, page 7 lines 1-2, FIG. 8b steps 456-466). When an element is modified, the element 
may be stored in its element chunk 320, which may be written to the computer readable medium 
without requiring the rewriting of the entire file in which the element chunk 320 is stored, and 
without moving the element chunk 320 to the end of the file leaving a hole in the file (specification, 
page 11, lines 31, FIG. 8b, steps 458-466). Instead, only the element chunk 320 containing the 
modified element is rewritten in the computer readable storage medium (specification page 1 1 , lines 
11-14). Additionally, the element chunk 320 may be compressed and/or encrypted before it is 
written tot the computer readable medium, without requiring the recompression or re-encryption of 
the entire file in which the element chunk 320 is stored (specification page 11, lines 1 1-14). 

Claim 83 recites: a computer readable medium for storing data for access by an application 
program, comprising: 

a file format 200 defining a structure of a file stored in said computer readable medium, the 
file format including (specification, page 6, lines 29-31; page 7, lines 1-2; page 8, lines 22-26; FIG. 
3) 

elements stored in the computer readable medium, the elements being variable sized data 
records arranged in a format that can be interpreted by a computer program (specification, page 7, 
lines 1-2; page 9, lines 22-26); 

element chunks 320 stored in the computer readable medium, the element chunks 320 being 
variable sized and including groups of the elements, the element chunks 320 having a unique name 
and a fixed header 325 including at least one of a number of elements in the element chunk 320, a 
compression scheme, or an encryption scheme for the elements (specification, page 11, lines 3-14, 
27-31; page 12, lines 1-5, 13-31; page 13, lines 10-22; FIG. 5, 320; FIG. 7, 320); 
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a model 310 stored in the computer readable medium, the model 310 including groups of 
related element chunks 320 and a model 314 header stream, the model header stream 314 including 
at least one of a model name, units, or a geometric range for the model (specification, page 9, lines 
23-30; page 10, lines 17-22; FIG. 4, 310, 314, 320; FIG. 5, 310); and 

a root storage 210 stored in the computer readable medium, the root storage 210 including at 
least one model 310 (specification, page 9, lines 3-5, 26-30; page 12, lines 3-4; FIG. 3, 210, 300). 

Claim 99 recites: a computer program product comprising a computer readable medium 
having a computer program logic stored therein, the computer program logic comprising: 

means for enabling said computer system to allocate elements having a variable size to 
element chunks 320, the element chunks 320 being variable sized and including groups of the 
elements, the element chunks 320 having a unique name and a fixed header 325 including at least 
one of a number of elements in the element chunk 320, a compression scheme, or an encryption 
scheme for the elements (specification, page 11, lines 3-14, 27-31; page 12, lines 1-5, 13-31; page 
13, lines 10-22; FIG. 5, 320; FIG. 7, 320); 

means for enabling said computing unit to store in the computer readable medium at least 
one model 310, wherein said at least one model 310 is for grouping related elements, is identifiable 
by a unique identifier, and comprises a control element list having variable sized element chunks 
320 containing control elements, and a graphic element list having variable sized element chunks 
320 containing graphic elements (specification, page 9, lines 23-30; page 10, lines 17-22; FIG. 4, 
310, 314, 320; FIG. 5, 310); and 

means for enabling a computing unit to store a root storage 210 comprising the model 310 in 
the computer readable medium (specification, page 9, lines 3-5, 26-30; page 12, lines 3-4; FIG. 3, 
210, 300). 

Claim 101 recites: a CAD design file having a file format 200 and stored on a computer 
readable medium, the CAD design file comprising: 
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elements representing items of the CAD design, the elements being variable sized 
data records arranged in a format that can be interpreted by a computer program (specification, page 
7, lines 1-2; page 9, lines 22-26; page 10 5 lines 25-29), 

element chunks 320 including groups of the elements, the element chunks 320 
having a unique name and a fixed header 325 including at least one of a number of elements in the 
element chunk 320, a compression scheme, or an encryption scheme for the elements, the element 
chunks 320 having a variable size, the groups of elements including control elements having no 
physical representation and graphic elements having a graphical representation (specification, page 
11, lines 3-14, 27-31; page 12, lines 1-5, 13-31; page 13, lines 10-22; FIG. 5, 320; FIG. 7, 320); 

a model 310, the model 310 including groups of related element chunks 320 and a 
model header stream 314, the model header stream 314 including at least one of a model 310 name, 
units, or a geometric range for the model 310 (specification, page 9, lines 23-30; page 10, lines 17- 
22; FIG. 4, 310, 314, 320; FIG. 5, 310); and 

a root storage 210 including at least one model 310 and a control model 310 storing 
information shared across other models 310 in the root storage 210 (specification, page 9, lines 3-5, 
26-30; page 12, lines 3-4; FIG. 3, 210, 300). 

Embodiments of the invention relate to a computer readable medium and CAD design file 
having a format for storing data for access by an application program. These embodiments provide 
numerous advantages over known computer readable mediums for storing data for access by an 
application program. Such advantages are described in the specification at page 6, lines 27-29, and 
page 11, lines 1 1-26, for example. The advantages include allowing large quantities of variable- 
sized data records to be stored on a storage medium in an enhanced file format 200 and to allowing 
efficient access and control over data stored in the enhanced file format 200. For example, one of 
the variable-sized data records stored on a storage medium in a file of the enhanced file format 200 
may be modified without requiring the entire file to be rewritten and without creating wasted space 
within the file. 
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These and other advantages are achievable with the embodiments recited, for example, 
in independent claim 83. As recited in independent claim 83, a computer readable medium for 
storing data for access by an application program is provided. In conventional computer readable 
mediums, data records stored in files must have a maximum size. If a data record is modified to 
exceed to this maximum size, either it must be rewritten at the end of the file, leaving a hole in the 
file where the data record was previously written, or the entire file must be rewritten to 
accommodate the increased size of the data record in the position where the data record was 
previously written. The modified data record may be compressed, but this still requires rewriting 
the entire file, as the entire file will need to be uncompressed and recompressed in order for the 
modified data record to be compressed. 

Accordingly, the embodiments allow for the variable-sized data records in a file stored 
on a computer readable medium to be modified, compressed and/or encrypted without requiring the 
entire file be rewritten, recompressed, or re-encrypted, and without leaving holes in the file due to 
data records being moved to the end of the file. 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Whether the Examiner has established that claims 83-94 and 99-1 12 are obvious in light 
of U.S. Patent Number 6,718,329 to Selvin view of U.S. Pub. No. 20010004245 from Shiba, and 
claims 95-98 and 1 13-1 16 are obvious in light of Selvin in view of Shiba in further view of U.S. 
Pub. No. 20020161608 from Loveland. 

VII. ARGUMENT 

Claims 83-1 16 recite a file format for storing a specific type of data (variable length 
CAD elements), that is carefully crafted and designed to facilitate a specific usage pattern 
(optimized saving of incremental changes to a subset of CAD elements in a large file). As is known 
to one of ordinary skill in the art, a file when used in connection with computer systems is an entity 
of data available to users of the system that can be manipulated as an entity. For example, a file can 
be moved from computer to computer, directory to directory, transmitted over a network, etc. A file 
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may be, for example, a Word document, which may be attached to an email and transmitted over a 
network to a recipient. All of the claims of the present application describe what is in the file and 
the format of the file. The cited art does not teach nor relate to a file format at all, and is related to 
the claimed invention only at a superficial level by virtue of common generic computer terminology 
as detailed below. 

Selvin describes a method for generating nodes and links for a hypertext database from a 
source document (Selvin, abstract). A source document is any data file that contains its data in text 
format (Selvin, col. 4, lines 21-26). Such a source document is divided into segments based on its 
format properties (Selvin, col. 4, lines 35-57, col. 5, lines 64-67, col. 6, lines 1-4), Nodes are 
generated to represent each segment, and links definitions are generated for links that will connect 
the generated nodes, so that the meaning of a link between two nodes can be determined from the 
link's definition (Selvin, col. 6, lines 4-6). The generated nodes and links are imported into a 
hypertext database, where they can be viewed with an application program capable of viewing 
hypertext (Selvin, col. 6, lines 6-9). For example, FIG. 4 of Selvin demonstrates a source document 
that has undergone the process of having nodes and links generated from it. The links and nodes 
that are the result of the process form a structural representation of the original source document 
that is suitable for conversion into hypertext data (Selvin, FIG. 4, 60, 60A, 60B, 60C, 70). 

Selvin does not disclose or suggest all of the elements of the present claims. Selvin is 
not in the same area as the present application, as Selvin does not disclose or suggest a new file 
format of any kind, as in claim 83, a computer readable medium comprising instructions for storing 
data on a computer readable medium, as in claim 99, or CAD file having a new file format, as in 
claim 101 . Selvin relies on existing file formats, for example, HTML documents, Microsoft Word 
and Excel documents, and CAD documents, but does not suggest any new manner in which the data 
in these documents may be stored on a computer readable medium (Selvin, col. 4, lines 19-34). The 
nodes and links generated from the source document do not constitute a file format, as suggested in 
the Action on page 2, paragraph 4. Instead, the nodes and links are data that may reference data in 
another previously existing file. It may be possible to store nodes and links in files but certainly 
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they do not in any way define a file format. In fact, Selvin' s mention of writing nodes to a file 
(Selvin col 9, lin3 45) is merely a transient text-file mechanism to import the data to a database. 

In contrast to Selvin, claim 83 of the present application discloses a new file format for 
storing data on a computer readable medium, one that is not a hypertext database. Selvin only 
discloses specific instances of using extant file formats, showing only that many file formats exist. 
Claim 83 recites the structure of a new file format that is not of the previous types, including 
hypertext databases. A file format, such as the file format recited in claim 83, governs the way in 
which the physical properties of a computer readable storage medium are manipulated in order to 
store data, whereas in Selvin all that is disclosed is a type of data structure. A data structure, such as 
that in Selvin, discloses nothing about how the data structure is physically stored on a computer 
readable storage medium. Selvin merely describes data that is stored in a hypertext database. 

The Action, on page 2, section 4, further aligns the hypertext database of Selvin with 
"defining a structure of a file stored in said computer readable medium." Again, Selvin has 
provided only a data type which may be stored on said computer readable medium, in this case, a 
hypertext database. Nowhere does Selvin disclose an actual structure for the hypertext database as 
it is stored on a computer readable medium (Selvin, col. 9, 16-20, FIG. 1, 44). This is wholly 
different from defining a structure of a file stored in said computer readable medium. Claim 83, in 
contrast to Selvin, recites a new structure for a file stored on a computer readable medium. This 
structure may define the way in which any data type may be written on to a computer readable 
medium, governing the way in which the physical properties of the computer readable medium are 
manipulated to represent data. 

The file format recited in claim 83 includes elements stored in the computer readable 
medium, the elements being variable sized data records. The Action, on page 3, aligns nodes and 
inter-node associations with elements stored in the computer readable medium, and suggests that the 
use of the word "length" discloses elements being variable sized data records (Selvin, col. 11, lines 
46-59, col. 7, lines 22-43). Elements, as defined in claim 83, are variable sized data records stored 
on a computer readable medium (specification, page 7, lines 1-2). Nodes and inter-node 
associations are data, but they are not elements themselves as they do no not define a file format 
structure on a computer readable medium. Selvin makes no mention of the format in which nodes 
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and inter-node associations are stored on a computer readable medium. Elements may store within 
them, on a computer readable medium, a wide variety of data types. Nodes and inter-node 
associations are data types and do not store other data types. 

Further, "length," as disclosed in Selvin, only pertains to the "LABEL field" of a node 
(Selvin, col. 7, 24-25). The length of said "LABEL field" of a node is "delimited by length or the 
format codes of source document 42" (Selvin, col. 7, lines 24-25). This is wholly different from 
having variable sized data records for elements. Selvin only discloses that some feature of the 
source document may delimit the length of one of the pieces of information contained within a 
node, the LABEL. In contrast, the variable sized data records recited in claim 83 are data records 
used to store elements and the length field of an Element is necessary to determine its size in bytes. 
It would make no sense to map the optional LABEL field mentioned in Selvin to the length of an 
Element, since one there cannot be an Element in the present invention without its length. 

Claim 83 further recites element chunks stored in the computer readable medium, the 
element chunks being variable sized and including groups of the elements, the element chunks 
having a unique name, a fixed header including at least one of an umber of elements in the element 
chunks. The Action on page 3 aligns element chunks with the LABEL field, CONTENT field and 
NODE TYPE field of Selvin. This contradicts the Action's previous alignment of elements with 
nodes and inter-node associations, as discussed above. LABEL field, CONTENT field, and NODE 
TYPE field are all data fields stored within a node (Selvin, col. 7, lines 21-42). Element chunks, as 
recited in claim 83, contain elements within them. Hence, if nodes and inter-node associations are 
aligned with elements, then in order for LABEL field, CONTENT field, and NODE TYPE field to 
be aligned with element chunks, the LABEL field, CONTENT field, and NODE TYPE field must 
contain nodes and inter-node associations, as element chunks contain elements. This is the opposite 
of what is disclosed in Selvin. Further, LABEL field, CONTENT field, and NODE TYPE field do 
not, independently of their relation to nodes, align with element chunks. Element chunks, as recited 
in claim 83, contain elements, which may store data of any type on the computer readable medium. 
An element chunk may contain as many elements as will fit into the size of the element chunk, and 
each element in the same element chunk may represent any type of data that an element may 
represent. 
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In contrast, the LABEL field, CONTENT field, and NODE TYPE field may each 
contain only a specific type of data. For example, a CONTENT field "contains the format codes 
and the remaining content of the paragraph" (Selvin, col. 7, lines 32-33). These restrictions on data 
type are not present in element chunks. Further still, the fixed header of an element chunk contains 
data relating to the elements stored within the element chunk, for example, how many elements 
there are and how they are encrypted or compressed, allowing for the reading of those elements off 
of the computer readable medium (specification, page 12, lines 13-21). The "heading" disclosed in 
Selvin is not actually a heading in and of itself. It is presented in Selvin as an example of the type 
of indicator that might be stored in the LABEL field of a node to help define the nodes relation to 
other nodes. The data in the LABEL field, i.e., "heading," plays no role in assisting with the 
reading of the contents of the node, and cannot contain data about the quantity of data stored in the 
node, or whether or not it is encrypted or compressed. The LABEL field may contain "heading", 
"paragraph", "heading 1", "paragraph 1", and so forth, as it is merely a descriptor of the node. 
(Selvin, col. 7, lines 22-43), and therefore is wholly different from the fixed header recited in claim 
83. 

Claim 83 also recites a model stored in the computer readable medium, the model 
including groups of related element chunks and a model header stream, the model header stream 
including at least one of a model name, units, or a geometric range for the model. Selvin does not 
disclose or suggest any of these features. The Action on page 3 aligns the "link-type" from Selvin 
with the model recited in claim 83. Link-types in Selvin are applied to links already generated 
between nodes, and serve only to "define further desired relationships between linked nodes" 
(Selvin, col. 11, lines 58-59). This has no relationship to a model as recited in claim 83, which may 
be a collection of elements that have been grouped together to be stored on a computer readable 
medium (specification, page 9, lines 23-30). As recited in claim 83, a model may be a structure 
written to a computer readable medium that contains element lists, which may be structures on the a 
computer readable medium which may contain element chunks, which may in turn be structures on 
the computer readable medium containing elements (FIG. 5, 310, 315, 320). Link-types do not 
contain anything aside from information further defining the link to which a link-type pertains 
(Selvin, col. 1 1 lines 59-59, col. 12, lines 2-8). Link-types do not define a structure for storing data 
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on a computer readable medium, as they are just data which may be stored on a computer readable 
medium in any appropriate format. Link-types, as disclosed in Selvin, are a wholly different 
concept from a model as recited in claim 83. 

The Action further aligns "heading" from Selvin with the model header stream recited in 
claim 23. As discussed above, "heading" in Selvin is merely an example given for the type of 
information that may be found in the LABEL field of the node, which may help to define the nodes 
relationship to other nodes (Selvin, col. 7, lines 22-43). As recited in claim 83, a model header 
stream may contain information specific to a model including at least one of the model name, the 
units, and the geometric range of the model, as well as any other information relevant to the model 
(specification, page 10, lines 12-22). A model header stream is therefore capable of storing more 
and different types of information than the LABEL field of a node in Selvin. Further, Selvin does 
not disclose or suggest anything similar to a model name, units or a geometric range being 
contained in the LABEL field. All that may be contained in the LABEL field for a node is the label, 
i.e., "heading", "headingl", etc., for that node that defines that node's relationship to other nodes 
(Selvin, col. 7, lines 22-43). These labels are relational descriptors and not units, as no units of any 
type are suggested, geometric ranges, as nothing similar to a geometric range is suggested, or model 
names, as the label must describe a relationship between nodes. 

Claim 83 further recites a root storage stored in the computer readable medium, the root 
storage including at least one model. This is also not disclosed or suggested by Selvin. The Action 
on page 3 aligns "a node" with a root storage. A node, as suggested in Selvin, is wholly different 
from a root storage. A node is a data structure which contains data and may include fields which 
specify particular properties or characteristics of the data (Selvin, col. 4 lines 58-63). A root storage 
is not a data structure, but is part of file format used in storing a data structure on a computer 
readable medium. A root storage is the starting point for reading or creating files on the computer 
readable medium in the file format disclosed in claim 83 (specification, page 9, lines 5-10). As 
such, a root storage may be used in a file on a computer readable medium which may contain a node 
of the type suggested in Selvin. However, a node as suggested in Selvin may not contain a root 
storage, because a node is a data structure that contains data, and a root storage is not, in itself, data. 
Therefore, a node and a root storage must be wholly different. If they disclosed the same concept or 
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feature, a root storage's ability to be used in a file format storing a node on a computer readable 
medium would also mean that a node would be capable of being used in a file format for storing a 
root storage on a computer readable medium. However, a node discloses nothing about the 
manipulation of the physical properties of a computer readable storage medium to store data. 

The Action on page 3 states that Selvin does not disclose or suggest the features recited 
in claim 83 of a compression scheme, or an encryption scheme for the elements. Shiba is cited as 
disclosing these features (Shiba, paragraph 27). Thus, Shiba is not cited as and does not cure the 
above-described the deficiencies of Selvin. 

With regards to independent claim 99, the Action cites the same sections of the prior art as 
discussed above for independent claim 83, so the arguments made above apply. The combination of 
Selvin and Shiba does not disclose or suggest any of the features of claim 99. 

With regards to independent claim 101 , the Action cites the same sections of the prior art as 
discussed above for claim 83, so the arguments made above apply. Further, Selvin does not disclose 
or suggest a CAD design having a file format, as stated in the Action on page 5. Selvin only 
mentions the existence of CAD programs in passing, nowhere in Selvin is a file format for storing a 
CAD file on computer readable medium disclosed. Selvin mentions that a "source document" may 
be able to be edited by a CAD program, implying that a "source document" may be a CAD file, 
which may then be stored in a hypertext database in a nodes and links data structure (Selvin, col. 4, 
lines 21-57). However, if anything, this may only imply a new data structure for a CAD file, not a 
new file format , as data structures and file formats are distinct concepts, as discussed above. The 
combination of Selvin and Shiba does not disclose or suggest any of the features of claim 99. 

Further, please see U.S. Patent No. 7,162,479 for Method and System for Storing Large Data 
Files, which issued to present Applicant on January 9, 2007. The claims from U.S. Patent No. 
7,162,479 cover subject matter similar to the subject matter covered by the claims of the present 
application, and their allowance is an indicator of the allowability of the claims of the present 
application. 

In view of the above discussion, it is clear that the cited reference fails to teach or suggest 
the features recited in the claims. Each of the dependent claims is allowable for at least the reasons 
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as being dependent from an allowable independent claim. For these reasons, the withdrawal of the 
rejections of claims 83-1 16 is respectfully requested. 



Dated: 



Respectfully submitted, 



By _L 

Jeffri 
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James R. Burdett 

Registration No.: 31,594 
VENABLE LLP 
P.O. Box 34385 
Washington, DC 20043-9998 
(202) 344-4000 
(202) 344-8300 (Fax) 
Attorney/Agent For Applicant 
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APPENDIX A 

Claims Involved in the Appeal of Application Serial No. 09/982,852 

83. A computer readable medium for storing data for access by an application program, 

comprising: 

a file format defining a structure of a file stored in said computer readable medium, the file 
format including, 

elements stored in the computer readable medium, the elements being variable sized data 
records arranged in a format that can be interpreted by a computer program, 

element chunks stored in the computer readable medium, the element chunks being variable 
sized and including groups of the elements, the element chunks having a unique name and a fixed 
header including at least one of a number of elements in the element chunk, a compression scheme, 
or an encryption scheme for the elements, 

a model stored in the computer readable medium, the model including groups of related 
element chunks and a model header stream, the model header stream including at least one of a 
model name, units, or a geometric range for the model, and 

a root storage stored in the computer readable medium, the root storage including at least 
one model. 

84. The computer readable medium of claim 83, further comprising element lists 
including element chunks classified according to their meaning in the model, the element lists 
including the unique name for each element chunk in the respective element list. 

85. The computer readable medium of claim 84, wherein the elements include 
control elements having no physical representation and graphic elements having a graphical 
representation. 
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86. The computer readable medium of claim 85, wherein the element lists include 
a graphic element list listing the graphic elements and a control element list listing the control 
elements. 

87. The computer readable medium of claim 83, wherein the element chunks 
include a fixed number of elements. 

88. The computer readable medium of claim 83, further comprising: 
a plurality of models; and 

a model directory stored in the root storage and including a list of the models, the models 
having a unique name within their respective model directory. 

89. The computer readable medium of claim 83, wherein the root storage further 
includes a file header stream, a session information stream, a manifest information stream, or a file 
properties stream stored therein. 

90. The computer readable medium of claim 83, further comprising a control 
model directly stored in the root storage and storing information shared across other models in the 
root storage. 

91 . The computer readable medium of claim 83, wherein said root storage further 
comprises a control model storage containing a control model header, a global control element list 
storage and a global graphic element list storage, wherein said global control element list storage 
and said global graphic element list storage contain element chunk including global elements. 

92. The computer readable medium of claim 91, wherein said global elements 
contain information relevant for all models in said model directory storage. 
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93. The computer readable medium of claim 86, wherein at least one element 
chunk in said graphic element list is compressed. 

94. The computer readable medium of claim 86, wherein at least one element 
chunk in said control element list is compressed. 

95. The computer readable medium of claim 86, wherein at least one element 
chunk in said graphic element list is encrypted. 

96. The computer readable medium of claim 86, wherein at least one element 
chunk in said control element list is encrypted. 

97. The computer readable medium of claim 86, wherein at least one element 
chunk in said control element list is encrypted and compressed. 

98. The computer readable medium of claim 86, wherein at least one element 
chunk in said graphic element list is encrypted and compressed. 

99. A computer program product comprising a computer readable medium 
having a computer program logic stored therein, the computer program logic comprising: 

means for enabling said computer system to allocate elements having a variable size to 
element chunks, the element chunks being variable sized and including groups of the elements, the 
element chunks having a unique name and a fixed header including at least one of a number of 
elements in the element chunk, a compression scheme, or an encryption scheme for the elements; 

means for enabling said computing unit to store in the computer readable medium at least 
one model, wherein said at least one model is for grouping related elements, is identifiable by a 
unique identifier, and comprises a control element list having variable sized element chunks 
containing control elements, and a graphic element list having variable sized element chunks 
containing graphic elements; and 
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means for enabling a computing unit to store a root storage comprising the model in the 
computer readable medium. 

1 00. The computer program product of claim 99, further comprising: 

means for compressing each element chunk stream to be stored in said graphic element list 
storage or said control model list storage in said control model directory, means for enabling said 
computer system to store a graphic element list storage and a control element list storage in each 
control model. 

101. A CAD design file having a file format and stored on a computer readable 
medium, the CAD design file comprising: 

elements representing items of the CAD design, the elements being variable sized data 
records arranged in a format that can be interpreted by a computer program, 

element chunks including groups of the elements, the element chunks having a unique name 
and a fixed header including at least one of a number of elements in the element chunk, a 
compression scheme, or an encryption scheme for the elements, the element chunks having a 
variable size, the groups of elements including control elements having no physical representation 
and graphic elements having a graphical representation, 

a model, the model including groups of related element chunks and a model header stream, 
the model header stream including at least one of a model name, units, or a geometric range for the 
model, and 

a root storage including at least one model and a control model storing information shared 
across other models in the root storage. 

102. The computer readable medium of claim 101, further comprising element lists 
including element chunks classified according to their meaning in the model, the element lists 
including the unique name for each element chunk in the respective element list. 
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103. The computer readable medium of claim 102, wherein the elements include 
control elements having no physical representation and graphic elements having a graphical 
representation. 

104. The computer readable medium of claim 103, wherein the element lists 
include a graphic element list listing the graphic elements and a control element list listing the 
control elements. 

105. The computer readable medium of claim 101, wherein the element chunks 
include a fixed number of elements. 

1 06. The computer readable medium of claim 101, further comprising: 
a plurality of models; and 

a model directory stored in the root storage and including a list of the models, the models 
having a unique name within their respective model directory. 

107. The computer readable medium of claim 101, wherein the root storage further 
includes a file header stream, a session information stream, a manifest information stream, or a file 
properties stream stored therein. 

108. The computer readable medium of claim 101, further comprising a control 
model directly stored in the root storage and storing information shared across other models in the 
root storage. 

109. The computer readable medium of claim 101, wherein said root storage 
further comprises a control model storage containing a control model header, a global control 
element list storage and a global graphic element list storage, wherein said global control element 
list storage and said global graphic element list storage contain element chunk including global 
elements. 
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1 1 0. The computer readable medium of claim 1 09, wherein said global elements 
contain information relevant for all models in said model directory storage. 

111. The computer readable medium of claim 1 04, wherein at least one element 
chunk in said graphic element list is compressed. 

1 12. The computer readable medium of claim 104, wherein at least one element 
chunk in said control element list is compressed. 

113. The computer readable medium of claim 104, wherein at least one element 
chunk in said graphic element list is encrypted. 

114. The computer readable medium of claim 104, wherein at least one element 
chunk in said control element list is encrypted. 

115. The computer readable medium of claim 104, wherein at least one element 
chunk in said control element list is encrypted and compressed. 

1 16. The computer readable medium of claim 104, wherein at least one element 
chunk in said graphic element list is encrypted and compressed. 
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APPENDIX B 

EVIDENCE 

No evidence pursuant to §§ 1.130, 1.131, or 1.132 or entered by or relied upon by the 
examiner is being submitted. 
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APPENDIX C 

RELATED PROCEEDINGS 

No related proceedings are referenced in II. above, or copies of decisions in related 
proceedings are not provided. 
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